home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_1199 / 1625 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  2.4 KB
  1. Date: Fri, 17 Jun 94 15:17 CDT
  2. From: ekl@sdf.lonestar.org (Evan K. Langlois)
  3. To: mint@atari.archive.umich.edu
  4. Subject: Device Drivers
  5.  
  6.  
  7. I'm been looking at the direction that MiNT has been going, basically,
  8. it seems as though XBIOS and BIOS functions will be provided by hooks
  9. into MiNT device drivers and the rest of GEMDOS will be put into MiNT
  10. also, so the end result is MiNT, device drivers, plus VDI+AES(optional),
  11. and maybe some ROM XBIOS functions that MiNT will have no need to duplicate,
  12. such as DSP functions.
  13.  
  14. Anyway, alot of people were talking about having a SCSI dev, and others
  15. wanted a device driver that operated at a lower level that didn't understand
  16. disks and such.   Can a driver in MiNT call another driver?   This would
  17. be very useful.  Then the /dev/harddisk driver can call /dev/dma and
  18. /dev/floppy can call /dev/dma or whatever names you want to give them.
  19. TTs and Falcon would have /dev/scsi (probably different drivers for
  20. each machine).  The names don't matter since they can be renamed.  Anyway,
  21. having one driver call another would also be useful for MiNT NET.  Can
  22. this be done?   If MiNT does not currently support this, what is involved in
  23. changing this?
  24.  
  25. Next thing I wanted to mention was filesystems.  I think someone mentioned
  26. that if a program was doing IO in a filesystem, and MiNT didn't lock access
  27. to the filesystem, that there would be problems because the filesystems
  28. weren't re-entrant?   Is this true?   If so, it would seem it would a
  29. problem of stacks.  If you call the filesystem code with a separate stack
  30. then wouldn't it become re-entrant?   Then what you would have is the
  31. app calling the filesystem code, say minixfs, which calls /dev/harddisk,
  32. /dev/harddisk queues the access until /dev/dma or /dev/scsi are free.
  33. /dev/dma then handles the IO or whatever.   I don't know which level
  34. would handle the queuing, but I would guess that all higher levels would
  35. need to be re-entrant, no?
  36.  
  37. Basically, I'm trying to get some more discussion on this, since I don't
  38. think anyone ever decided how it would all work.  I have the ehscsi driver
  39. that someone posted, but its useless without a Falcon.  Does anyone have
  40. any files that describe how the ACSI DMA status and mode control regs
  41. are manipulated (0xff8606) and the disk data path reg (0xff8604) and I assume
  42. that second is for floppy only?
  43.  
  44. I'm thinking of disassembling AHDI or Supra (since its only 2K) drivers to
  45. see how they work.
  46.  
  47.